Skip to content

Store credentials in Secrets Manager consistently + configurable KMS key - #8

Merged
sebastiancorrea81 merged 2 commits into
mainfrom
feature/rds-secrets-manager
Aug 24, 2026
Merged

Store credentials in Secrets Manager consistently + configurable KMS key#8
sebastiancorrea81 merged 2 commits into
mainfrom
feature/rds-secrets-manager

Conversation

@sebastiancorrea81

Copy link
Copy Markdown
Contributor

Summary

  • fix(rds-postgres-db): app-level PostgreSQL credentials generated by db_setup are now also stored in Secrets Manager (nullplatform/rds/<service_id>/app), matching how rds-postgres-server already handles the master password. Previously they only lived in Terraform state and as a plain nullplatform service/link attribute. The new secret is destroyed alongside the app user on service delete, and its ARN is exposed as app_secret_arn on service/link attributes. The rds-postgres-db IAM policy is widened from read-only GetSecretValue to full secret lifecycle management, scoped to the same nullplatform/rds/* prefix.
  • feat(rds-postgres-server): added an optional secret_kms_key_id parameter (Terraform variable + UI-exposed field) so each instance can use its own customer-managed KMS key to encrypt its master secret. Left unset, it keeps using the default aws/secretsmanager managed key.

Test plan

  • terraform fmt/validate pass on rds-postgres-server/deployment and rds-postgres-db/db_setup (done locally)
  • Apply rds-postgres-server requirements/deployment in a test account, confirm secret_kms_key_id left empty still creates the secret with the default AWS-managed key
  • Set secret_kms_key_id to a customer-managed key ARN, confirm the master secret is encrypted with it
  • Create an rds-postgres-db service end-to-end, confirm aws_secretsmanager_secret nullplatform/rds/<service_id>/app is created with the correct credentials
  • Delete the service, confirm the app secret is destroyed alongside the app user/password
  • Confirm link/unlink still work and app_secret_arn shows up in service and link attributes

🤖 Generated with Claude Code

sebas_correa and others added 2 commits August 18, 2026 11:06
…urable

Add an optional secret_kms_key_id parameter (Terraform variable, service
attribute, and UI-exposed field in the service spec) so each
rds-postgres-server instance can use its own customer-managed KMS key
to encrypt its master password secret. Left unset, the secret keeps
using the default aws/secretsmanager managed key, same as before.

Also thread the same variable through the currently-unused
rds-postgres-db/deployment module to keep it consistent with
rds-postgres-server's, since both define an equivalent
aws_secretsmanager_secret.master resource.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Previously the app user's credentials generated by db_setup lived only
in the Terraform state and as a plain nullplatform service/link
attribute — unlike rds-postgres-server, which stores its master
password in Secrets Manager. Add an aws_secretsmanager_secret/_version
pair (nullplatform/rds/<service_id>/app) alongside the existing
postgresql_role, following the same naming convention as the master
secret, and expose its ARN as app_secret_arn on both the service and
link attributes.

Wire the new region variable and aws provider into db_setup (needed to
create the secret), destroy the secret alongside the app user/password
on service delete, and widen the rds-postgres-db IAM policy from
read-only GetSecretValue to full secret lifecycle management, scoped to
the same nullplatform/rds/* prefix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Comment on lines +44 to +52
resource "aws_secretsmanager_secret" "app" {
name = "nullplatform/rds/${var.service_id}/app"
recovery_window_in_days = 0

tags = {
"managed-by" = "nullplatform"
"service-id" = var.service_id
}
}
@sebastiancorrea81
sebastiancorrea81 merged commit d308763 into main Aug 24, 2026
6 checks passed
@sebastiancorrea81
sebastiancorrea81 deleted the feature/rds-secrets-manager branch August 24, 2026 11:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants